Method for loading flight schedule modifications

ABSTRACT

A method for loading flight schedule modifications in an air travel computerized reservation system, wherein: the flight schedule database is updated; the reservations concerned by the flight schedule modifications are reassigned to update the reservation inventory database. The method for loading flight schedule modifications includes the following steps: receiving at least one lot of modifications containing flight schedule modification data, retrieving individual modifications contained in the lot and storing in a register in the form of records for future scheduling, simulating reassignment of the reservations concerned by the flight schedule modification, by accessing with the reservation distribution server both the records and the flight schedule database, final updating of the flight schedule databases and of the reservation inventory. The method is useful for updating databases during flight schedule modifications in computerized reservation systems.

The present invention relates to a method of loading flight schedulingchanges into a computerized air transport reservation system.

The scheduling changes in such systems require very large manipulationsof the existing schedule database.

Flight schedule describes the manner in which the aerial network isfollowed by the aircraft. Scheduling is calculated for the purpose ofoptimizing the connection between flights, use of aircraft and theoccupation of seats. Changes to be given to an existing schedule are forthis reason generally changes which are not isolated, which have apossible impact on correspondence with other flight operations.

At present, flight schedules are subject to more and morereorganization, given the composition, the need for agreement betweenthe airlines and the sophistication of the computer means to establishschedules.

Usually, the airlines make scheduling changes one after the other.During these changes, the person charged with making the changes has noknowledge of the seat reservations existing on aircraft which he ischanging.

The aircraft reservation inventory system applies changes to theschedule database without being capable of apprehending over all thenumber of changes and modifications which this involves.

The present procedure used, consisting in applying scheduling changesone after the other, has a first drawback which consists of the factthat the reservations already made are generally changed more often thannecessary. This situation arises particularly if the passengers arerescheduled for another flight and this latter is accordingly subject toa change. In this latter case, it is necessary further to modify thepassenger reservation.

Passenger reservation changes are costly because they give rise tomanual intervention on the part of travel agents, network costs andcomputer processing.

Another drawback of the present methods used, is that large changes tobe given to an existing schedule database can occupy a long time becausethe repercussions on the reservations of the passengers must be analyzedmanually on a case by case basis.

The object of the invention is to provide a solution to the problem offlight scheduling changes in a computerized air transport reservationsystem.

To provide for this purpose a new method in which there is used updatingof the flight schedule database and the assignment of the reservationsin question by changes of flight scheduling for updating the reservationinventory database, in a particular manner.

A first advantage of the invention is to method a plurality of flightscheduling changes in an overall manner, which permits envisaging theassignment of passenger reservations taking account of the integralityof these changes, no matter what the order of the changes in thescheduling modification file.

Moreover, according to the invention, the scheduling changes are appliedby means of a simulation without final activation, which avoids risks ofdisturbance of the existing database before complete finalization andvalidation of the update.

To provide an overall choice in the reassignment of passengerreservations, the invention permits the server to have access both tothe existing database and to new records corresponding to futureschedule which is to be used.

It will be noted that the gains of efficiency of the invention areparticularly great, especially given the massive overall character ofthe scheduling changes to be carried out.

By way of example, there can be distinguished different types ofprocedure for scheduling changes:

-   -   seasonal changes which comprise massive scheduling changes        varying in size from 2000 to 8000 lines and which generally        require a validation of several instances of the control        organization of the computerized air transport reservation        system,    -   readjustments. Generally, it is a matter of changes affecting        flights and a near departure date and for which the reassignment        of the reservations is particularly important and requires        particular consideration.    -   regular changes which can be carried out in a largely automatic        fashion, given their nature.

The present invention permits loading such changes no matter what theirnature and also permits controlling an assembly of automation parametersof the updates to be carried out.

Within this scope, there can be easily be adjusted the level of manualcontrol to be performed for the changes in question.

Other objects and advantages will become apparent from the course of thedescription which follows, of a preferred embodiment of the invention,which is however not limiting.

The present invention relates to a method for loading flight schedulechanges in a computerized air transport reservation system, in which:

-   -   the flight schedule database is updated;    -   the reservations in question by changes of flight schedules are        reassigned to update the reservation inventory database,

characterized by the fact that it comprises the following steps:

-   -   reception of at least one group of changes containing flight        scheduling change data,    -   extraction of the individual changes contained in the group and        storing in a register as future schedule records,    -   simulation of the assignment of the reservations in question by        scheduling changes, by access of the reservation distribution        server both to the records and to the flight schedule database,    -   final updating of the flight schedule and of the reservations        inventory databases.

This method will preferably have the following modifications, accordingto which:

-   -   there is used a graphical user interface for verification of the        changes in the group of changes.    -   there is used a graphical interface user for the validation of        the reassignments of reservations.    -   there is assigned a characteristic suffix (SL) to the changes to        be stored as future schedule records (FSR)    -   there is assigned to each record (FSR) an argument (FSR is        published) indicating whether this record (FSR) has been made        accessible to the reservation distribution server.    -   for each change extracted:    -   flight periods are opened from the flight schedule database that        are affected by the change;    -   if said period has not already been assigned by a change whose        argument (FSR is published) is positive, said period is        duplicated and the suffix (SL) is attached to the duplicated        period;    -   there is sent a scheduling change message to integrate the        change into the duplicated period that it affects;    -   it is indicated that the change is record accessible to the        reservation distribution server by placing its argument (FSR is        published) in the positive state.    -   upon simulation of reassignment, the dependencies between        records are updated given that a record A depends on a record B        if and only if the reassignment of the passengers upon the        application of record A that takes place for future schedule        described in record B.    -   in the case of cyclical dependence between several records, upon        the execution of the reassignment operations in the reservation        system, one modifies only once and each reservation in question        by all of these reassignments.    -   the records (FSR) are deleted after final updating of the flight        schedule and of the reservations inventory databases.

The accompanying drawings are given by way of example and do not limitthe invention. They represent only one embodiment of the invention andpermit its easy comprehension.

FIG. 1 shows schematically the configuration of different computer meansadapted to be used to practice the invention.

FIGS. 2 and 3 are block diagrams of various successive steps of thepresent invention.

Referring to FIG. 1, it is shown that the method given here can use thescheduling change server SLS adapted to receive a group of schedulingchange tasks to be carried out. Moreover, this change server SLS isaccessible to a user such as an analyst or a supervisor by means of agraphical user interface GUI in particular for verification of thechanges made in the change file constituting the group of change tasksand for the validation of the reassignments of reservations.

A portion of the steps of the method of the invention can moreover becarried out in the distribution portion of the reservation system in thedistribution server CS and of the existing database db1 comprising thedatabase of reservation inventories and the flight schedule database.

In the scheduling change server SLS, upon the arrival of a group ofchanges, it is possible in the first instance to verify the integrity ofthe changes and of the possible conflict problems, to test theautomation rules and to render the data accessible by means of thegraphical utilizer interface GUI.

At this stage, different automation criteria could be carried out foreach of the groups of changes to be made. In particular, the automationcriteria concern the automation of the scheduling changes and theautomation of the reservation reassignments. According to the value ofthese parameters, the changes can be processed manually or automaticallyor else can have certain manual steps and certain automated steps.

Preferably, analytical interveners perform a step of validationaccording to the processing and automation parameters which have beenprovided.

If desired, a supervisor can also carry out a verification thereafter.These steps of validation which lead to signature by the analysts and ofthe supervisor, are shown in FIG. 2.

At the end of these steps, it is possible to produce future schedulerecords which can be used by the central system in the distributionserver CS. To this end, there is stored in a register of the differentchanges from the group of changes received in the form of futureschedule records FSR.

The future schedule records FSR are rated accessible by the distributionserver CS in the form of a publication. There will be described onepossibility for a procedure provided for this purpose:

-   -   we start by determining the list of scheduling changes which        must be published as future schedule records FSR. In this way,        there are omitted all the changes which have no impact on the        reassignments of the reservations, in particular changes which        relate only to updating of service such as providing onboard        airline meals.    -   for each of the scheduling changes of the list, there are        carried out the following:    -   there is assigned to each record FSR a suffix SL which permits        characterizing as a future schedule record FSR relative to the        other data accessible by the distribution CS,    -   there is assigned to each record FSR an argument, for example        called “FSR is published” indicating whether this record FSR has        been rendered accessible to the reservation distribution server        CS or not. If the argument “FSR is published” is true, this        means that the record FSR is accessible,    -   there are noted, in the existing schedule, the flight periods        which are affected by the change in question.    -   for each of these affected periods, researched whether it is        already concerned by a schedule change which would have an        argument “FSR is published” identified as true. If this is not        the case, this period is duplicated by assigning the suffix SL.        If the argument “FSR is published” is already true for a        preceding change, it means that this period has already been        duplicated. At this stage, the central system thus has a        duplicate of the current schedule with the suffixes SL.    -   there is thus sent a schedule change message for the data having        the suffix SL, this message describing how the future scheduling        must be handled. The central system thus has future schedules        perfectly described in the periods in question to which are        assigned the suffix SL.    -   for this change of schedule, the argument “FSR is published” is        placed in the condition of being true.

These different operations are then repeated for all the schedulingchanges contained in the group until they all have an argument “FSR ispublished” in the true column.

Following these steps, the central system, and particularly thedistribution service CS, is capable of accessing the future schedulerecords FSR so as to find the best flight alternatives duringreassignment of the reservation.

It is this step which is then carried out.

There will be described hereafter in greater detail a preferredembodiment.

When it is completed and the updating of the databases is final, it willbe possible to delete the future schedule records FSR.

There will now be described more precisely the steps of simulation ofthe reassignment of the reservation which precede the final updating ofthe flight and reservation schedule databases.

The reservation system automatically selects a reassignment option (foreach change of scheduling requiring it). This option is selected fromamong the future schedules FSR or the current schedules (for flights notaffected by the group in progress).

Once the automatic reassignment options are evaluated, the systemverifies them thanks to the reassignment automation rules. Thereassignments not satisfying these rules are subjected to validation byan operator (who will then modify the options automatically calculatedby the system).

When all the reassignments have been validated, the application properlyso called of the group of changes in the reservation system can begin.

To this end, it should first be noted that the reassignment ofpassengers rise problems of interdependence of the flights. There ismeant by dependency between two scheduling changes, the necessity, tocarry out a change (S1 for example) relating to flight F1, to reassigncertain passengers from the flight F1 to a future schedule S2 concerninga flight F2.

Moreover, there can be encountered questions of cyclic dependency inwhich the dependence of the flights is reciprocal.

In this context (for example suppose two scheduling changes S1 and S2relating to flights F1 and F2 involve the reassignment of reservationsof F1 to the future schedule of F2 and the reassignment of thereservations of F2 to the future schedule of F1), it would be necessary,during execution of the reassignments in the reservation system, ofmodifying only once each reservation in the context of a group ofchanges of reservation (so as to avoid in our example the passengers notbeing reassigned to future schedule of F2 and then again toward futureschedule of F1).

During the execution of the group of scheduling changes, the scheduledatabase is first of all updated.

The system then allocates the single operation identifier “I”characterizing the group in progress. The reservation system thenreceives the assembly of reassignment instructions as well as theoperation identifier “I”. It must then guarantee the uniqueness ofmodification of each reservation in the context of the operation “I”.

The preferred embodiment of this constraint consists for eachmodification of reservation, to:

-   -   verify that this reservation does not have the mark “I”,    -   modifying the reservation in this case    -   then marking the modified reservation with the identifier “I”.

To the extent of reassignments, the inventory database is also updated.

The three databases (inventory, reservation and schedule) are then up todate and the FSR records can be deleted.

REFERENCES

-   -   SLS: Schedule change server    -   CS: Distribution server    -   db1: Existing database    -   GUI: Graphical user interface

1. Method for loading data relating to aircraft scheduling changes intoa computerized air transport reservation system, in which: the flightschedule database is updated; the reservations in question by aircraftscheduling changes are reassigned to update the reservation inventorydatabase, characterized by the fact that it comprises the followingsteps: reception of at least one group of changes containing aircraftscheduling change data, extracting from the group of changes that itcontains and storing in a record as future schedule records (FSR)connecting the future schedule record (FSR) and a reservationdistribution server, simulation of reassignment of the reservations inquestion prior to the scheduling changes, by access of the reservationdistribution server both to the records (FSR) and to the flight scheduledatabase, final updating of the flight schedule and reservationinventory databases.
 2. Method according to claim 1 characterized by thefact: that there is used a graphical user interface for verification ofthe changes extracted from the group of changes.
 3. Method according toclaim 1 characterized by the fact that there is used a graphical userinterface for the validation of the reservation reassignments.
 4. Methodaccording to claim 1 characterized by the fact that a characteristicsuffix (SL) is assigned to the changes to be stored as future schedulerecords (FSR).
 5. Method according to claim 4 characterized by the factthat there is assigned to each record (FSR) an argument (FSR ispublished) indicating whether this record (FSR) has been made accessibleto the reservation distribution server.
 6. Method according to claim 4in combination, characterized by the fact that for each extractedchange: the flight periods of the flight schedule database affected bythe change, are opened; if said period has not already been affected byone change whose argument (FSR is published) is positive, said period isduplicated and the suffix (SL) is assigned to the duplicated period; ascheduling change message is sent to integrate the change in theduplicated period that it affects; it is indicated that the change is arecord accessible to the reservation distribution server, by placing itsargument (FSR is published) in the positive state.
 7. Method accordingto claim 1 characterized by the fact that upon simulation ofreassignment, there is attributed to each record a degree of dependenceas a function of the number of other records in cascade for which anapplication of said record gives rise to a reassignment of thereservations on said other records.
 8. Method according to claim 7characterized by the fact that in the case of cyclical dependencebetween several records, upon the execution of the reassignmentoperations in the reservation system, there is modified only once eachreservation in question by the assembly of these reassignments. 9.Method according to claim 1 characterized by the fact that that therecords (FSR) are deleted after final updating of the flight scheduleand the reservation inventory databases.
 10. Method according to claim 2characterized by the fact that there is used a graphical user interfacefor the validation of the reservation reassignments.
 11. Methodaccording to claim 2 characterized by the fact that a characteristicsuffix (SL) is assigned to the changes to be stored as future schedulerecords (FSR).
 12. Method according to claim 3 characterized by the factthat a characteristic suffix (SL) is assigned to the changes to bestored as future schedule records (FSR).
 13. Method according to claim 2characterized by the fact that there is assigned to each record (FSR) anargument (FSR is published) indicating whether this record (FSR) hasbeen made accessible to the reservation distribution server.
 14. Methodaccording to claim 3 characterized by the fact that there is assigned toeach record (FSR) an argument (FSR is published) indicating whether thisrecord (FSR) has been made accessible to the reservation distributionserver.
 15. Method according to claim 4 characterized by the fact thatthere is assigned to each record (FSR) an argument (FSR is published)indicating whether this record (FSR) has been made accessible to thereservation distribution server.
 16. Method according to claim 2characterized by the fact that upon simulation of reassignment, there isattributed to each record a degree of dependence as a function of thenumber of other records in cascade for which an application of saidrecord gives rise to a reassignment of the reservations on said otherrecords.
 17. Method according to claim 3 characterized by the fact thatupon simulation of reassignment, there is attributed to each record adegree of dependence as a function of the number of other records incascade for which an application of said record gives rise to areassignment of the reservations on said other records.
 18. Methodaccording to claim 4 characterized by the fact that upon simulation ofreassignment, there is attributed to each record a degree of dependenceas a function of the number of other records in cascade for which anapplication of said record gives rise to a reassignment of thereservations on said other records.
 19. Method according to claim 5characterized by the fact that upon simulation of reassignment, there isattributed to each record a degree of dependence as a function of thenumber of other records in cascade for which an application of saidrecord gives rise to a reassignment of the reservations on said otherrecords.
 20. Method according to claim 6 characterized by the fact thatupon simulation of reassignment, there is attributed to each record adegree of dependence as a function of the number of other records incascade for which an application of said record gives rise to areassignment of the reservations on said other records.